BigDFT build tree offers the possibility to have non-regression tests. When the user (or the devloper) types make check in the distribution, a number of tests are passed. Then a the script is checking that the logfiles of each run coincides with the reference results that are provided for each test. Ideally, each functionality of the code should have its own test, to ensure that further developments do not break it. It is therefore responsibility of the developer to provide new non-regression tests for each of the functionality. The optimal test should be

  • Reasonably fast (roughly less than 1 min on a monocore run)

  • Reasonably exhaustive (if the test passes this means that the functionality is indeed preserved - no false positive)

Clearly, these two requirements contradict each other. The art of the developer is to find a good compromise to reassure: 1) the other developers not to slow down the make check execution, and 2) himself, to be sure that new developments still would preserve the functionality.

Having said that, imagine that we have a set of files that we would like to use for non regression. There are different steps to include them in the test farm of BigDFT.

As an example, we show the insertion of the test for the molecular dynamics in BigDFT.

Prepare the directory

The tests should go in the tests directory (rather unexpectedly… ;)). The procedure described here is valid for four subdirectories: cubic, linear, overDFT and tutorials. All the other directories have special Makefiles associated and have a less easy way to automatize the test procedure. As our examples are related to MD, we put our tests in the overDFT directory. We create the directory MD:

cd tests/overDFT
bzr mkdir MD

Once this is done, all the test files inside this directory should correspond to a particular naming scheme. For example, a test named foo have to be associated to two reference files: named MD_foo.out.ref, containing the standard output (which essentially only contains one line with the name of the logfile), and MD_foo.out.ref.yaml which contains the lofgile associated to the test foo. Clearly, also the input files foo.yaml and (or any other supported format have to be present, as if it was a normal running directory. THe presence of the two reference files will cause the check procedure to run

$run_parallel ``\ \ ``/src/bigdft foo -l yes

where run_parallel is the environment variable containing the desired command to run tests. These tests will be ran in the directory tests/overDFT/MD-test/ of the build tree, to preserve untouched the input files and the references. The logfile of the run will be written in the file log-foo.yaml of the same directory.

Let us imagine we would like to insert two tests, with codename LJ-NVE and LJ-NVT. According to the above instruction, we therefore have to add the following files:

> ls MD/
>  LJ-NVE.yaml LJ-NVT.yaml  MD_LJ-NVE.out.ref  MD_LJ-NVE.out.ref.yaml  MD_LJ-NVT.out.ref  MD_LJ-NVT.out.ref.yaml  psppar.LJ

The directory might contain also extra files, that are needed for the run, in this case psppar.LJ. We should not froget to also add these files to the development branch:

> bzr add tests/overDFT/MD
adding tests/overDFT/MD/
adding tests/overDFT/MD/LJ-NVE.yaml
adding tests/overDFT/MD/
adding tests/overDFT/MD/LJ-NVT.yaml
adding tests/overDFT/MD/MD_LJ-NVE.out.ref
adding tests/overDFT/MD/MD_LJ-NVE.out.ref.yaml
adding tests/overDFT/MD/MD_LJ-NVT.out.ref
adding tests/overDFT/MD/MD_LJ-NVT.out.ref.yaml

Insert the test in the make check command

Even if the directory is ready, the test is still not active. To activate it in the make check procedure, the developer has to tell the build system that MD is a valid test directory. To do that, it is enough to insert the name of the directory (MD in our example) in the file of the tests/overDFT directory:

# Give here the list of existing tests
    FF-LJ \
    H2O-slab \
    H2-freq \
    MD #<<<< add it here...


    C6H6-freq \
    GEOPT-all \
        [...] #<<< ...or here

As it can be seen, the MD directory can be added either in the SHORT_TESTDIRS or in the LONG_TESTDIRS variable, but not in the two. Whether to choose one or another is a matter of the importance/robustness of the test: the tests in SHORT_TESTDIRS are ran by anybody typing make check on the released version whereas the others are only run by developers and expert users. Therefore a test in SHORT_TESTDIRS shoudl be.. short, and also should fail only when there are major instabilities in the code.

Running the tests and prepare tolerances

Even though an output file is prepared, we cannot expect the output of the test to be bitwise identical to the provided output. It is therefore responsibility of the ‘test forger’ to provide a set of tolerances for any of the fields of the output file (which for this reason is in markup language). This require some running of the tests to have an idea of the correct tolerances. To run the test the first time, let us go to the build tree (not in the source tree and execute a check for the MD test:

> cd ``\ \ ``/tests/overDFT
> make MD.check

This last command will, in the order:

  • Create the test directory MD-test in the build tree.

  • Copy the corresponding input files in such a directory.

  • Run the bigdft executable in the folder, with the command

$run_parallel ``\ \ ``/src/bigdft ``\ \ `` -l yes

where is each of the test runs (NVE and NVT in the examples defined above).

  • Once the test is finished, the fldiff scripts are ran to compare the logfiles of the output witrh the given references.

As all the log of the run are written in markup language, the different fields of the logfile might be compared with different tolerances. Such information is stored in the tests/tols-BigDFT.yaml file. Such file might be modified to adapt the tolerance of each field to the nature of the run.